FIG. 1 is a diagram of a conventional computer system 140 having a bridge 150 between two busses 160, 170 that have a different protocol from one another. A processor local bus 160 interfaces with the processor, the random access memory 102, and the bus master 162. A peripheral bus 170 interfaces with peripherals, such as a keyboard 106 and a UART 172 (Universal Asynchronous Receiver-Transmitter). The bridge 150 connects the two busses 160, 170 and performs a conversion between the different protocols used by the two busses 160, 170 such that communication between devices on the two busses 160, 170 is possible. Thus, it is useful to be able to provide a conversion between two protocols that differ from one another but have the same notion of information being transported. The example in FIG. 1 is just one use case illustrating an application of a conversion between two protocols that differ from one another but that have the same notion of information being transported.
One of the steps in designing and developing bridges that perform protocol conversion is creation of a description of the bridge at a level of abstraction that is suitable for use by a development tool that allows analysis and verification of the design. For example, if a register-transfer-level (RTL) description of the bridge can be created, then further steps in the design process are greatly facilitated. The RTL description may be input into a synthesis tool, such as Design Compiler™ available commercially from Synopsys of Mountain View, Calif. Among other benefits, the Design Compiler™ tool is able to produce a gate-level design based on the RTL description. However, conventionally the creation of the RTL description of protocol conversion bridges presents several problems.
Conventionally, a description of a protocol conversion that is suitable to synthesize a bridge is typically written by hand. Writing the description of the protocol conversion for the bridge is a very error prone and tedious process, as many factors have to be taken into consideration when making the protocol conversion.
There have been suggestions to automate the process of generating a description of a protocol conversion for a bridge. However, these suggestions have significant limitations. A limitation of at least some conventional techniques is that the protocol conversion is only applicable for a single transaction. Therefore, this solution is incompatible with protocols that use pipelining. A further limitation of conventional techniques of automating the process of protocol conversion is that they are not efficient with respect to timing or storage. For example, one conventional solution requires that the entire transaction that is the subject of the protocol conversion be buffered. Buffering the entire transaction requires a substantial amount of memory to be used in the final bridge implementation; therefore, this solution is not storage efficient. Another conventional solution requires that the protocol on either one of the sides of the transaction be slowed down to wait until the other side has finished. For example, this technique adds more wait states than are needed. This may cause the ready pin to be kept low for longer than is required or the acknowledgement to be asserted later than possible. Thus, this solution is not timing efficient and the communication bandwidth is reduced.
Another application of protocol conversion is protocol insertion. This may be used to create a bridge between the peripheral's protocol and the protocol of a bus to which the peripheral connects. A further complication in this case is that the peripheral may be modeled at a higher level of abstraction than the RTL level. For example, the peripheral may be modeled at the transaction level (TLM). Thus, protocol insertion may be used to refine the communication part of peripherals modeled at a higher level of abstraction (e.g., TLM) to a lower level of abstraction (e.g., RTL) by creating and inserting the interface logic to connect the peripheral to an on-chip-bus. Conventionally, the process of providing the interface between the peripheral and the bus is a tedious and error prone process that is performed manually.